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Special Use IPv4 Addresses 
Abstract 


This document obsoletes RFC 3330. It describes the global and other 
specialized IPv4 address blocks that have been assigned by the 
Internet Assigned Numbers Authority (IANA). It does not address IPv4 
address space assigned to operators and users through the Regional 
Internet Registries, nor does it address IPv4 address space assigned 
directly by IANA prior to the creation of the Regional Internet 
Registries. It also does not address allocations or assignments of 
IPv6 addresses or autonomous system numbers. 


Status of This Memo 
This memo documents an Internet Best Current Practice. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


BCPs is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5735. 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
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include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


Throughout its history, the Internet has employed a central Internet 
Assigned Numbers Authority (IANA) responsible for the allocation and 
assignment of various identifiers needed for the operation of the 


Internet [RFC1174]. In the case of the IPv4 address space, the IANA 
allocates parts of the address space to Regional Internet Registries 
(RIRs) according to their established needs. These RIRs are 


responsible for the registration of IPv4 addresses to operators and 
users of the Internet within their regions. 


On an ongoing basis, the IANA has been designated by the IETF to make 
assignments in support of the Internet Standards Process [RFC2860]. 
Section 4 of that document describes that assignment process. 


Small portions of the IPv4 address space have been allocated or 
assigned directly by the IANA for global or other specialized 
purposes. These allocations and assignments have been documented in 
a variety of RFCs and other documents. This document is intended to 
collect these scattered references and provide a current list of 
special use IPv4 addresses. 


This document is a revision of RFC 3330 [RFC3330], which it 
obsoletes; its primary purpose is to reflect the changes to the list 
of special IPv4 assignments since the publication of RFC 3330. It is 
a companion to [RFC5156], which describes special IPv6é addresses. 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, [RFC2119]. 


Global and Other Specialized Address Blocks 


0.0.0.0/8 - Addresses in this block refer to source hosts on "this" 
network. Address 0.0.0.0/32 may be used as a source address for this 
host on this network; other addresses within 0.0.0.0/8 may be used to 
refer to specified hosts on this network ([RFC1122], Section 

Sia 2relt 32s 


10.0.0.0/8 - This block is set aside for use in private networks. 
Its intended use is documented in [RFC1918]. As described in that 
RFC, addresses within this block do not legitimately appear on the 
public Internet. These addresses can be used without any 
coordination with IANA or an Internet registry. 
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127.0.0.0/8 - This block is assigned for use as the Internet host 
loopback address. A datagram sent by a higher-level protocol to an 
address anywhere within this block loops back inside the host. This 
is ordinarily implemented using only 127.0.0.1/32 for loopback. As 
described in [RFC1122], Section 3.2.1.3, addresses within the entire 
127.0.0.0/8 block do not legitimately appear on any network anywhere. 


169.254.0.0/16 - This is the "link local" block. As described in 
[RFC3927], it is allocated for communication between hosts ona 
single link. Hosts obtain these addresses by auto-configuration, 
such as when a DHCP server cannot be found. 


172.16.0.0/12 - This block is set aside for use in private networks. 
Its intended use is documented in [RFC1918]. As described in that 
RFC, addresses within this block do not legitimately appear on the 
public Internet. These addresses can be used without any 
coordination with IANA or an Internet registry. 


192.0.0.0/24 - This block is reserved for IETF protocol assignments. 
At the time of writing this document, there are no current 
assignments. Allocation policy for future assignments is given in 
[RFC5736]. 


192.0.2.0/24 - This block is assigned as "TEST-NET-1" for use in 
documentation and example code. It is often used in conjunction with 
domain names example.com or example.net in vendor and protocol 
documentation. As described in [RFC5737], addresses within this 
block do not legitimately appear on the public Internet and can be 
used without any coordination with IANA or an Internet registry. See 
[RFC1166]. 


192.88.99.0/24 - This block is allocated for use as 6to4 relay 


anycast addresses, in [RFC3068]. In contrast with previously 
described blocks, packets destined to addresses from this block do 
appear in the public Internet. [RFC3068], Section 7, describes 


operational practices to prevent the malicious use of this block in 
routing protocols. 


192.168.0.0/16 - This block is set aside for use in private networks. 


Its intended use is documented in [RFC1918]. As described in that 
RFC, addresses within this block do not legitimately appear on the 
public Internet. These addresses can be used without any 


coordination with IANA or an Internet registry. 
198.18.0.0/15 - This block has been allocated for use in benchmark 


tests of network interconnect devices. [RFC2544] explains that this 
range was assigned to minimize the chance of conflict in case a 
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testing device were to be accidentally connected to part of the 
Internet. Packets with source addresses from this range are not 
meant to be forwarded across the Internet. 


198.51.100.0/24 - This block is assigned as "TEST-NET-2" for use in 
documentation and example code. It is often used in conjunction with 
domain names example.com or example.net in vendor and protocol 
documentation. As described in [RFC5737], addresses within this 
block do not legitimately appear on the public Internet and can be 
used without any coordination with IANA or an Internet registry. 


203.0.113.0/24 - This block is assigned as "TEST-NET-3" for use in 
documentation and example code. It is often used in conjunction with 
domain names example.com or example.net in vendor and protocol 
documentation. As described in [RFC5737], addresses within this 
block do not legitimately appear on the public Internet and can be 
used without any coordination with IANA or an Internet registry. 


224.0.0.0/4 - This block, formerly known as the Class D address 
space, is allocated for use in IPv4 multicast address assignments. 
The IANA guidelines for assignments from this space are described in 
[RFC3171]. 


240.0.0.0/4 - This block, formerly known as the Class E address 
space, is reserved for future use; see [RFC1112], Section 4. 


The one exception to this is the "limited broadcast" destination 
address 255.255.255.255. As described in [RFC0919] and [RFC0922], 
packets with this destination address are not forwarded at the IP 
layer. 
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4. Summary Table 


Address Block 


Special Use IPv4 Addresses 


Present Use 


January 2010 


Reference 


0.0.0.0/8 
10.0.0.0/8 
127.0.0.0/8 
169.254.0.0/16 
172.16.0.0/12 
192.0.0.0/24 
192.0.2.0/24 
192.88.99.0/24 
192.168.0.0/16 
198.18.0.0/15 


198.51.100.0/24 
203.0.113.0/24 
224.0.0.0/4 
240.0.0.0/4 
255.255.255.255/32 


5. Assignments of 


"This" Network 
Private-Use Networks 
Loopback 

Link Local 

Private-Use Networks 
IETF Protocol Assignments 
TEST-NET-1 

6to4 Relay Anycast 
Private-Use Networks 
Network Interconnect 
Device Benchmark Testing 
TEST-NET-2 

TEST-NET-3 

Multicast 

Reserved for Future Use 
Limited Broadcast 


IPv4 Blocks for New Specialized 


1122,- Section 3.2.1.3 
1918 
1122; 
3927 
1918 
5736 
5737 
3068 
1918 


Section 3.2.1.3 


2544 
5737 
5737 
3171 
1112, 
919, 
922, 


Section 4 
Section 7 
Section 7 


Uses 


The IANA has responsibility for making assignments of protocol 
parameters used in the Internet according to the requirements of the 
"Memorandum of Understanding Concerning the Technical Work of the 


Internet Assigned Numbers Authority" 
requires that protocol parameters be assigned according to 
the criteria and procedures specified in RFCs, 
and full Internet Standards and Best Current Practice 
and any other RFC that calls for IANA assignment. 


[RFC2860] 


Draft, 
documents, 


The domain name and IP address spaces involve policy issues 
so that the requirements of [RFC2860] 
Nonetheless, 


addition to technical issues) 
do not apply generally to those spaces. 


[RFC2860]. 


Among other things, 


including Proposed, 


(in 


the IANA is 


responsible for ensuring assignments of IPv4 addresses as needed in 
support of the Internet Standards Process. 


IPv4 address space is specifically required by an RFC, 
for the portion should be 
Immediately before the RFC is published, the 
in consultation with the Regional Internet Registries, 


requirements 


IANA will, 


(e.g.,; 
described [RFC5226]. 


size, prefix length) 


When a portion of the 
the technical 


make the necessary assignment and notify the RFC Editor of the 
particulars for inclusion in the RFC as published. 


As required by [RFC2860], 
experimental assignments of IPv4 addresses, 


the Regional Internet Registries. 
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the IANA will also make necessary 


also in consultation with 
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6. IANA Considerations 


This document describes the IANA’s past and current practices and 
does not create any new requirements for assignments or allocations 
by the IANA. 


7. Security Considerations 


The particular assigned values of special use IPv4 addresses 
cataloged in this document do not directly raise security issues. 
However, the Internet does not inherently protect against abuse of 
these addresses. If you expect (for instance) that all packets from 
a private address space such as the 10.0.0.0/8 block or the link 
local block 169.254.0.0/16 originate within your subnet, all routers 
at the border of your network should filter such packets that 
originate from outside your network. Attacks have been mounted that 
depend on the unexpected use of some of these addresses. 


It should also be noted that some of these address spaces may be used 
legitimately outside a single administrative domain, and may appear 
on the global Internet. Security policy SHOULD NOT blindly filter 
all of these address spaces without due consideration, and network 
operators are encouraged to review this document, and references 
contained therein, and determine what security policies should be 
associated with each of these address blocks within their specific 
operating environments. 
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Appendix A. Differences between This Document and RFC 3330 


Address blocks that were reserved for a special purpose in RFC 3330 
but are no longer reserved for any special purpose and are available 
for allocation are no longer listed in Sections 4 or 5. The 
following blocks have become available: 


- 14.0.0.0/8 is no longer set aside for assignments to the 
international system of Public Data Networks [RFC1700], page 181. 
It is now available for allocation to RIRs in the normal way. 


- 24.0.0.0/8 is no longer listed as the addresses in that block have 
been managed by the American Registry for Internet Numbers (ARIN) 
in the normal way since 2001. 


- 39.0.0.0/8 is no longer listed as it has been subject to 
allocation to an RIR for assignment in the normal manner since 
2001. 


- 128.0.0.0/16 is not reserved and is subject to future allocation 
by a Regional Internet Registry for assignment in the normal 


manner. 


- 191.255.0.0/16 is not reserved and is subject to future allocation 
by a RIR for assignment in the normal manner. 


- 198.51.100.0/24 is assigned as "TEST-NET-2" for use in 
documentation and example code. 


- 203.0.113.0/24 is assigned as "TEST-NET-3" for use in 
documentation and example code. 


- 223.255.255.0/24 is not reserved and is subject to future 
allocation by an RIR for assignment in the normal manner. 
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